Subject: DLSw: "To IETF or not to IETF..."

From: [email-masked] (Elazar (Azi) Ronen)
Date: Thu, 05 May 1994 12:00:00 +0200

RADLINX's vote is for option 2 "Post AIW DLSw closed pages as an 
informational RFC", for the following reasons:

1. We need one "Industry Standard" - and we need it fast

We need an "Industry Standard", that allows interoperability among vendors. 
The AIW process is faster, already started and is in a good postion to have 
a final document. The AIW is also acceptable by all players in the industry, 
therefor fulfilling this major requirement.

We are late so far, and adding more 'overhead', starting a new process, with 
new partners and different procedures will not help.

2. Risk of having two standards

Working with both AIW and IETF has the risk of having two standards, with a 
significant interval of time between the two. This will prevent vendors from 
implementing DLSw, due to the uncertainty about which is the standard 
(mainly due to the reason that the AIW will be the first). Today's status 
(of having the current 6611/RFC1434 DLSw and the 'future standard')is 
confusing enough - we do not need more!

3. Informational RFC is good enough

The term RFCxxx is good enough for our customers. They know that this means 
a well defined document, publicly available. The precise status is not 
important.

Azi Ronen, RADLINX
---------------------------------------------------------------
Elazar (Azi) Ronen                  Phone: +972 3-6475188
RADLINX Ltd.                        FAX  : +972 3-6475057
Tel-Aviv, Israel                    Email: [email-masked]

---

From: [email-masked] (David Matusow)
Date: Wed, 11 May 94 12:36:32 -0400

>  1)  No relationship at all.
>  2)  Post AIW DLSw closed pages as an informational RFC.  
>  3)  Pursue DLSw IETF standard after AIW DLSw closed 
>          pages.
>  4)  Pursue DLSw IETF standard in parallel with pursuing 
>          AIW closed pages.

We feel that the timing is important, but if the changes from 1437 to the 
current state of DLSw is an indication, running serially will not get us 
where our customers want; that is, a interoperable methodology.  Our 
customers vary between IETF stamps being a checkmark to a requirement.  In 
my dealings recently, standards are becoming a clearer requirement, 
though.  With this in mind, we feel that:

1. DLSw must go through the IETF

   Without this "certification", our work will not be recognized.

2. running serially will NOT get us where we need to be 

   Our customers will be spooked by running in serial to the AIW.  This is 
   because they either strongly desire a standard or demand one.  Running 
   serially will result in a lapse between AIW agreement and the IETF 
   "blessed" standard.  This timegap results in too long of a delay.

3. we may get more insight from the IETF members

   We are all smart, but there may be some insight from the IETF that we 
   are not looking at.  This may be a result of a closed environment and 
   none of us seeing some beautiful (or ugly) result of a decision.  (I 
   don't put much credence in this, as none of us are truely or even 
   symbolically closed, but you never know.)

As a result, Hypercom would vote for concurrent development.  We don't 
feel that this should slow us up much, as the active participants will 
largely be those that are in AIW.  The intellectual property rights issue 
is not seen strongly by us.  We're here to submit input and make the 
solution better, not get highly involved in lawsuits in intellectual 
property.

I hope that this helps...or atleast clarifies our viewpoint.

David Matusow
Hypercom Network Systems

---

From: [email-masked] (Mike Otto)
Date: Thu, 12 May 94 15:19:18 EST

Netlink's opinion regarding DLSw is to produce an IETF standard
DLSw document in conjunction with producing the AIW closed pages
(option #4).

Reasons for our choice:

At present, the IETF is highly visible and has a very successful track
record for producing industry recognized standards. This carries a
great deal of weight in the decision making process of our customers.
What confidence level will our customers have that a DLSw
implementation from the AIW standard will inter-operate with one from
the IETF standard?  Working in parallel will help to ensure that we
produce a single standard DLSw specification. A synchronous approach
(option #3) runs the risk of having two separate DLSw standards being
produced, which will cause much confusion with our customers.

The DLSw group has already announced to the press that we are working
towards producing an IETF DLSw document. A change in plans could send
the wrong message to the user community that we have been unsuccessful
in our efforts to produce an industry standard DLSw document. Working
in parallel with the IETF to produce a single open DLSw standard will
help add credibility to the AIW's efforts towards becoming an industry
recognized standards body.

At present, the IETF members showing interest in producing a DLSw
standard are largely a subset of the AIW DLSw group. And, since both
groups work through a general consensus to make decisions, the
process of working in parallel with the IETF should not prove to be
difficult and time consuming.

Rgds,

Mike Otto
Netlink Inc.

---

From: "Wayne Cullen" <[email-masked]>
Date: Fri, 13 May 94 09:16:03 EST

Reasons for our choice:

Rgds,

Mike Otto
Netlink Inc.
******************************************************************************
*        Mike H. Otto                       Telephone: (919) 878 8612        *
*        Netlink, Inc.                      Fax:       (919) 872 2132        *
*        3214 Spring Forest Road            Internet:  [email-masked]       *
*        Raleigh,  NC  27604                                                 *
******************************************************************************

---

From: Bill Kwan <[email-masked]>
Date: Mon, 16 May 94 18:11:17 EST

Text item: Text_1

Dear DLSw Riggers,

I think it would be a mistake to back out pursuing a full IETF standard at
this time. It will send a confusing and wrong message to the industry and 
our customers. Everybody is expecting this group to create a fully 
interoperable IETF standard. To do a reversal now will do serious damage to 
the group's credibility.

I agree with those that pointed out the fact that an informational RFC is
not a legitimate standard. An informational RFC is intended for someone to
present their views or information that may be of interest to the Internet
community. In many ways, this is not much different to someone submitting a 
technical paper to be published for a conference (but maybe with slightly 
more rigor). In fact, in RFC 1602 section 2.4, it warns against developers 
trying to bypass the IETF process by publishing an Informational RFC and 
relying on the prestige of the RFC label to gain community support for their 
document. Although we are not trying to do that, the IETF will still 
definitely frown upon any abuse of the process. 

If there is sufficent concern with the confusion of having two standards 
(AIW and IETF), we might want to consider a fifth alternative. We can
look at not pursuing an AIW closed pages, but just an IETF RFC. We will 
meet at the AIW as an IETF working group. This will be comparable to 
how the SNA MIB working groups are currently operating (and rather 
successfully in my opinion). This will not necessarily eliminate any of the 
issues of having to meet at both standard bodies, but the outcome 
will be only one standard. If we need to choose between which standard to
pursue, I think it should be the IETF RFC.

CrossComm would like to pick the most expeditious path to get to a 
full IETF standard and think we should consider this new option. 
However, if this alternative is not acceptable then we would vote
for choice #4 to pursue the IETF standard in parallel with AIW closed pages.

Regards,

Bill Kwan
CrossComm Corp.